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METHOD OF CONVERTING HTML/XML 

■ 

TO HDMLAVML IN REAL-TIME 
FOR DISPLAY ON MOBILE DEVICES 

r 

■ 

Background of the Invention 

1 . Field of the In ven tio n 

'The present invention relates generally to wireless communications and more particularly 

relates to a method for converting HTMLVXML to HDMLAVML in real time for display on mobile 
devices. 

2. Related Art 

The advent of wireless personal communications devices has revolutionized the 
telecommunications industry. Cellular, personal communications services ('TCS") and other 
services provide wireless personal communications to businesses and individuals at home, in the 
office, on the road, and any other location the wireless network may reach. Wireless telephone 
subscribers must no longer use public telephones along the road, wait until returning to the home or 
office to check messages, or wait to return important business calls. Instead, wireless subscribers 
can carry out day-to-day business from the privacy of an automobile, from a remote job site, while 

■ 

walking along the airport concourse, and anywhere else that a personal communications signal is 
accessible. 

Thus, it is no surprise that since the introduction of the cellular telephone service, the number 
of wireless telephone subscribers has increased steadily. Today, there are a staggering number of 

wireless telephone subscribers whose ranks are growing rapidly, hi fact, many households have 

, — "\ 

! 

multiple wireless telephones in addition to their conventional land line services. 

# ■ 
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With a market of this size, there is fierce competition among hardware manufacturers and 
service providers. In an attempt to lure customers, most providers offer handsets with desirable 
features or attributes such as small size, light weight, longer battery life, speed dial, and the like. 
Many recent additions to the marketplace include multi-functional handsets that even provide pocket 
organizer functions integrated into the wireless handset Most manufacturers, however, are still 
scrambling to add new features to their communications devices to snare a portion of this booming 

■ 

market. 

One way in which new features are added to wireless communication devices is by 

integrating the device into the Web. This allows the countless services available through the Web 
■ ■ " 

to be extended to a wireless communications device. However, traditional web pages typically 
contain too much information to be advantageously presented on the smaller display of a wireless 
communication device such as a digital cellular telephone. Therefore, new Web based programming 
languages such as the Handheld Device Markup Language ('T3DML") have been developed to serve 

* 

the wireless market. In serving the wireless market, HDML has evolved and is now called the 
Wireless Markup Language ("WML"), and will be herein referred to as HDML/WML. 

HDML/WML is part of a larger body called the Wireless Application Protocol ("WAP"), 
which is a result of continuous work to define an industry wide standard for developing applications 
over wireless networks. The WAP forum was formed to create the global wireless protocol 
specification that works across differing wireless network technology types for adoption by 
appropriate industry standards bodies. HDML/WML is a markup language intended for use in 
, specifying content and user interfaces for narrow bandwidth ("narrowband*') devices, including 

■ 

cellular phones, pagers, and personal digital assistants ("PDA"). HDML/WML was designed with 
the limitations and constraints of these narrowband, small screen devices specifically in mind. .Some 
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of these constraints include (1) the small display and limited user input facilities; (2) the narrowband 

■ 

network connection; and (3) the limited memory and computational resources. 

HDML/WML was designed with four major functional areas. First, the text presentation and 
layout area includes text and image support, Including a variety of formatting and layout commands. 
Second, a "card and deck" organizational metaphor whereby all information is organized into a 
collection of screen sized cards that comprise decks. Third, inter-card navigation and linking is 
supported for explicitly managing the navigation between cards and decks. Finally, the fourth major 
functional area in HDML/WML is string parameterization and state management that allows the use 

■ -i 

of a state model to add parameters to the decks. 

Today, TZDML/WML offers an efficient means of providing content and services from the 
Web infrastructure to wireless handheld devices such as cellular phones, pagers, and PDAs, 
Unfortunately, the vast majority of content on the Web is created in hpyer text markup language or 
extensible markup language ("HT3VDL/XML") and is thus not useful on the constrained wireless 
communication devices. HTML/XML requires significant context to he useful. The constrained 
display and restricted resources of wireless devices reduce the context to such a level that 
HTML/XML becomes unusable. The pull down menu for navigational history and the context 
sensitive forward and back buttons are simply not available through the small screens of wireless 
mobile devices such as cellular phones, pagers, and PDAs. 

m 

Although most Web content is unusable on wireless communications devices, certain types 
of information are desirable to wireless device users. For example, Web pages with time sensitive, 
discrete data such as stock quotes, weather reports, email, calendar and appointment data, inventory 
data, price lists, corporate directories, white and yellow pages, and invoice status. Thus, there is a 

■ 
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need to provide existing HTML/XML Web content to wireless communication devices with 
constrained displays and limited computational resources such as RAM and processing power. 

Summary of the Invention 

Accordingly, an advantage of the present invention is that it allows for the conversion of 
HTML/XML content from the Web to HDML/WML content for a wireless communications device, 

■ 

An additional advantage of the present invention is that the HDML/WML content is optimized for 
display on wireless communication devices. The conversion takes place in a conversion server that 
acts as a proxy server for the wireless communications device. This proxy function allows the 
conversion server to receive and process all Web related requests from the mobile unit. 

4 

Additionally, the proxy/communication server receives all of the corresponding responses and 
channels those responses to the mobile unit after conversion to HDML/WML. Furthermore, the 
proxy/communication server can be configured to restrict certain types of requests, responses, and 
connections. 

The HTML/XML to HDML/WML conversion process begins with a request from the 
wireless device. This request is received by the conversion server, acting as a proxy for the mobile 

■ 

■ 

unit. In addition to the actual request for Web content, the wireless device sends certain user data 

■ 

and device data. This additional data is maintained by the mobile unit for identification purposes. 
The user and device data, therefore, allow the server to identify (with the required degree of 

■ 

certainty) the type of mobile device making the request and the preferences of the user making the 
request. 

Upon receiving the request, the conversion server retrieves the desired content from the Web 
in the form of an HTML/XML document Alternatively, if the requested document has been 
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previously retrieved by the conversion server, the document may be located in the server's local 
cache. If so, the conversion server retrieves the document from its local cache. This decreases the 

t 

overall response time to the mobile unit by eliminating the otherwise necessary Web access step. 

After the conversion server has retrieved the requested document, the server examines the 
user data and device data received in the request. Based on the user information, device information, 
and the type of data contained in the requested HTML/XML document, the server selects the 
appropriate conversion specification. The conversion server then retrieves the appropriate 
conversion specification from its local database for use in the conversion process. 

v 

The conversion process follows the instructions in the conversion specification, making 
necessary allowances based on the user information, device information, and" the' type of data 
contained in the requested HTML/XML document. The conversion server runs the retrieved Web 
document through a series of conversion routines to convert the content into a format that is 
appropriate for the specific device. When the conversion is complete, the conversion server 
optimizes the data for display on the requesting mobile unit and transmits the data to the waiting 
wireless communications device. 



Brief Description of the Drawing s 

■ 

The details of the present invention, both as to its structure and operation, can best be 
understood in reference to the accompanying drawings, in which like reference numerals refer to like 
parts, and in which: 

Figure I is a diagram illustrating a wireless communication device; 
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Figure 2 is a block diagram portraying a wireless communication system according to the 
present invention; 

Figure 3 is a flowchart depicting a method for requesting information across a wireless 

T 

network according to the present invention; 

Figure 4 is, a block diagram illustrating a wireless communication system that links a 

■ 

wireless communications device to the World Wide Web according to the present invention; 

Figure 5 is a flowchart of a process for receiving HTML/XML content from the Web and 
converting it to HDML/WML content for a wireless communications device; and 

Figure 6 is a flowchart of a method for converting HTML/XML content to HDML/WML 
content according to the present invention. 
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Detailed Description of the Preferred Embodiments of the Invention 

■ 

The present invention is directed toward a method for converting Web content in 

HTML/XML format to HDML/WML format for eventual display on a mobile wireless 

communications device. In one example embodiment, the mobile device can be a digital cellular 

telephone that connects to a Web server using wireless communications technology. After reading 

this description it will become apparent to one of ordinary skill in the art how to implement the 

invention in alternative embodiments and alternative, applications. As such, this detailed description 

of a preferred and alternative embodiments should not be construed to limit the scope or breadth of 

the present invention, 
* 

1. Introduction and Overview 

* 

• The present invention provides a method for converting HTML/XML to HDML/WML such 
that native Web content can be efficiently displayed on a mobile wireless communications device. 
In one embodiment, the wireless communications device sends its requests for Internet content to 

■ 

a Web server that acts as a proxy for Internet related requests from the mobile device. Examples of 
requests that maybe sent from the mobile device include Web search requests, Yellow Page lookup 
requests, informational queries, and any other requests that may be useful or valuable to users of 
Web content. The wireless communication device sends, along with its request for content from the 
Web, certain local information to uniquely identify the mobile device and the preferences of the user 
of the mobile wireless device* After the request has been processed by the Web server, the result 

■ 

■ 

is translated into HDML/WML and optimized for transmission back to the mobile wireless 
communications device. 
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2. Example Environment 

Before describing the invention in detail, it is useful to describe an example environment in 

■ 

which the invention can be implemented. One example environment is a handset or communication 
device operating within a wireless communication network such as, for example, a cellular, GSM, 

+ 

PCS or radio communication network- Wireless communication devices embodying the present 
invention can be implemented in various configurations and architectures. Typically, a wireless 
communication device will include a keypad for control of the device and data entry, and a display 
for displaying relevant information. 

An example wireless communication device 100 is illustrated in Figure 1* Communication 
device 100 is presented for illustrative purposes only; implementation of the invention is not 
dependent on any particular device architecture or communication network. 

m 

Device 100 includes a processor 104, a speaker 106, a display 108, a keypad 110, a 
transceiver 122, a memory 1 14, a microphone 116, a power source 118 and an antenna 120. Device 
100 is typically a mobile device such as a handheld handset or an integrated vehicle phone. It is 
configured to communicate with other communications devices such as base station 112. Base 
station 1 12 is typically within a geographic area known as a "cell" and handles communications for 
all wireless devices within the cell. 

Processor 104 directs the overall operation of device 100. A computer program or set of 
instructions is typically coded or otherwise implemented on the processor to enable theprocessor 
to cany out the device operation* Memory 1 14 interfaces with processor 104 and may store program 
code and provide storage space for data useful in executing the program code and carrying out the 
device functions. Memory 114 may be implemented as read only memory ("ROM")* random access 
memory ("RAM") or any other convenient memory format. The features and functionality of the 

i I 
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invention described below may be implemented using hardware, software, or a combination thereof, 
and such software can run on a processor such as processor 1 04 and be stored in a memory such as 
memory 114. 

Transceiver 122 includes a transmitter that .transmits voice and data information via antenna 
120 to a recipient communication device such as, for example, base station 112. Transceiver 122 
also includes a receiver that receives voice and data information from another communication device 
(e.g,, base station 1 12). The received voice and data information is provided to the user or used to 
facilitate device operation. 

User interface features include speaker 1 06; display 1 08, keypad 110, and microphone 1 1 6. 

¥ 

Microphone 116 accepts voice or other audio information from the user and converts this 
information into electrical signals that can be transmitted by transceiver 122, Likewise, speaker 106 
converts electrical signals received by transceiver 122 into audio information that can be heard by 
a user of device 100. Display 108 displays information such as call information, keypad entry 
information, signal presence and strength information, battery life information, or any other 
information useful to the user. Display 108 preferably takes the form of a liquid crystal display 
("LCD"), which has low power consumption characteristics, but could also be implemented as a 
light emitting diode (""LED**) display or any other appropriate visual indicator. Keypad 1 10 typically 
includes an alphanumeric keypad and may also include special function keys. Id one embodiment, 
keypad 1 10 is backlit to permit viewing of the keys in low light or dark conditions. Device 100 may 

4 

also include a flip panel (not shown) that can be closed to conceal part or all of the keypad 1 10. 

Power source 118 provides power to device 100. It can be implemented with rechargeable 
batteries, such as NiCad or NiMH rechargeable batteries, or with any other suitable power source. 
3, Wireless Services Through a Web Server 
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Figure 2 is a block diagram illustrating a wireless communication system according to the 
present invention. The communication system provides information to a wireless device user based 
on the location of the user and his device. It includes a wireless handset 130 and a hands-free unit 
132 incorporating a position determination system 134, Handset 130 can be implemented in a 
configuration such as device 100 of Figure 1, or in any other wireless communication device 
capable of communicating with remote locations via a wireless communication medium. In the 
description below, handset" refers to any communication device capable of communicating with 
other devices via a wireless medium. 

Hands-free unit 132 is optionally provided to allow the user of wireless device 130 to 
communicate in a hands-free mode. Hands-free unit 132 may include a microphone and speaker to 
provide wireless device 130 with speakerphone-like capabilities. Such capabilities are particularly 
desirable, where wireless device 130 is utilized in an automobile or other mobile situation. In one 
implementation, hands-free unit 132 is configured according to conventional industry standards for 
a "hands-free kit." 

As mentioned above, in addition to the conventional standards, hands-free unit 132 is 
equipped in a preferred embodiment with a position determination system 134 to determine the 
location of hands-free unit 132 and handset 130. Alternatively! position determination system 134 

■ 

may be directly incorporated into handset 130, Position determination system 134 determines 

■ 

location in terms of parameters such as latitude, longitude, height, speed of travel, and any other 
useful location or position parameters. In one embodiment, position determination system 134 is 
implemented using a global positioning system ("GPS") or differential GPS. The design and 
configuration of a GPS is well known to those of ordinary skill in the art. Alternative position 
determination systems may also be employed. 
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One example of an alternative position determination system is a triangulation system. In 
such a system, the position of handset 130 is determined by triangulating a signal from handset 130 
with the fixed locations of two or more base stations. Triangulation systems, though u&efiil and 
relatively inexpensive, have several drawbacks. Errors due to multipath signal transmission may 
occur and the systems may be inoperable in areas where only one base station is available. 

Wireless device 130 preferably includes both a voice and data interface, particularly where 
position determination system 134 is incorporated in a hands-free unit 132, The voice interface 
provides hands-free operation and speakerphone-like capabilities. The data interface allows position 
information obtained by system 134 to be provided to handset 130 for transmission over wireless 
network 140, Moreover, where voice recognition or speech synthesis capabilities are provided 
(discussion below), the data interface provides the data to be synthesized into speech or the data 

■ 

received via voice recognition. 

Handset 130 communicates with other entities via wireless network 140, Network 140 is 
typically comprised of a plurality of base stations that provide relay points for communication. 
Network 140 may be a cellular, PCS, GSM, or any other wireless communication network. In 

■ 

addition to conventional communication with other wired or wireless communication devices, as 
shown in Figure 2, network 140 permits communication between handset 130 and data server(s) 
136. When a user requests information, handset 130 provides the location of the handset to server 

w 

136 across wireless network 140, Server 136 retrieves relevant information from an associated 
database 138 and conveys the information to handset 130 over wireless network 140, The 
information may be displayed on the handset display or audibly rendered via speech synthesis or 
prerecorded scripts. Although the type of information stored in database 138 is virtually limitless, 
several example applications are provided for illustrative purposes. 
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In one example application, driving directions to a destination address are provided to a 

■ * 

handset user. The user requests driving directions to the destination via keypad entry and/or voice 
command, and the request is communicated to server 136 over wireless network 140. At the time 
of the request, the handset location determined by position determination system 134 is also 
provided to server 136 to provide a starting point for the directions. Using the handset location and 

4 

the destination address, server 1 36 calculates a route and compiles driving directions. The driving 
directions are transmitted to handset 130 over network 140 and are displayed or audibly rendered 

* 

to the user. In addition to textual driving directions, a map showing the route may be displayed on 
the handset display. Options such as the shortest possible route, interstate route, safest route, most 
scenic route, etc. may be provided. The user's choice of options will dictate the route calculation. 

■ 

The options may be stored locally and prompts or scripts generated in the memory of handset 130. 
Alternatively, the options, prompts and scripts may be stored at server 136 and provided to the user 
via network 140, 

M 

I m 

Another example application locates particular types of businesses or services in the user's 
location. Restaurants, gas stations, hotels and other businesses or services near the user's location 
can be identified and provided to the user. Again, the user requests the business or service type 
vocally or via keypad entry. The request is communicated to server 136 over wireless network 140, 
along with the user's current location as determined by the position determination system 134. 
Server 136, based on the handset location and user request retrieves and returns relevant information 

a 

* 

to handset 130 over network 140. 

Parameter limits or filters may be implemented to refine the request and selections returned. 
The user may set a location filter, for example, that requires returned selections be within a certain 
maximum number of miles of the user's current location. If the user is seeking a restaurant, the user 
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may request or be prompted to select parameters that refine the search results. These parameters 
may include cuisine type (e.g., Italian, French, American, etc.), restaurant type (e.g., fast food, casual 
dining, formal, etc*)* price range and so on. Additionally, for restaurants, gas stations, motels and 
other businesses, the user may identify a preferred national or regional chain. Alternatively, the user 
may have a preferences profile stored in the Web server 136 that contains this information. 

As noted above, the search may be refined (the query narrowed) on the user's own initiative 
or based on system prompts. If the user simply requests a nearby restaurant, for example, server 136 
may prompt the user with questions about parameters such as those described above. Alternatively, 

P 

to conserve bandwidth over network 140, prompts can be stored locally and made by handset 130 
(or hands-free unit 132) before the request is sent to server 136. In this embodiment, updated scripts 

■ 

and/or prompts may be downloaded from server 136 to handset 130. Preferably, memory-intensive 
data such as establishment locations, driving directions, etc. are stored in database 138 to minimize 
the amount of memory required in handset 130. The precise distribution of data storage among these 
devices will be influenced by factors such as available bandwidth, memory costs and airtime costs. 

The user may also specify avoidance of certain areas or parts of town, such as those that have 
high crime rates, gang or drug activity, or other undesirable attributes. Crime statistics from law 
enforcement authorities or other sources can be compiled and stored in database 138. Based on these 
statistics, certain areas or neighborhoods may be identified as high crime rate areas or otherwise 
undesirable areas. The user may opt to not receive choices for establishments in, or driving 
directions through, those areas. This feature can be implemented automatically, as a default 
selection or through a user prompt. Alternatively, the system may provide an automatic warning 

■ 

sound or indication to alert the user of entry into a high-crime-rate area. This feature is particularly 
useful if the user is unfamiliar with a particular area in which he or she is travelling. 

■r 
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A method for requesting information across network 140 is illustrated in Figure 3. In step 
202, a user initiates a request for information. As described above, this request can be made via a 
keypad entry or by voice command with an appropriate voice recognition system. In step 204, the 

■ 

■ 

system determines whether the request requires the handset location or position. If all information 
is based on positional information, this step can be eliminated on the assumption that answering any 
request requires positional information* Since many requests may be fulfilled based on previously 
transmitted position information or without any position information at all* however, inclusion of 
step 204 is preferable to avoid unnecessary transmission of position information over network 140. 

If position information is required, the method proceeds from step 204 to step 212, where 
position determination device 134 acquires the position of handset 130. In one implementation, 
position determination occurs regularly while handset 130 (or hands-free unit 132) is powered on. 
If position determination device 134 is situated in hands-free unit 132, unit 132 provides the 
position data to handset 130 for transmission to server 136 over wireless network 140 (step 214). 

■ 

If position information is not required, the method proceeds from step 204 directly to step 206. 

* 

In step 206, handset 130 sends the request to server 136 via wireless network 140. The 
request includes any position data acquired in steps 212-214* In step 208, server 136 retrieves the 
data or information requested from database 138. The data may be retrievable and usable in raw 
form, or it may need to be processed. This determination is based on the type of request, the 
information requested, and the manner or format in which the infonnation is stored in database 138. 
The raw or processed data is communicated to handset 130 over network 140 and, in step 210, is 
displayed or provided to the user* 

As described above, scripts or prompts may be provided to the user to refine the infonnation 
request. If the scripts or prompts are stored in database 138 (as opposed to local storage in handset 
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130), they are retrieved by server 136 in step 208 and provided to the user in step 210. The user's 
answers to the prompts are sent by handset 130 to server 136, which uses the refined information to 
retrieve additional data or information from database 138, or to further refine the user's query. This ' 
potentially repetitive process is illustrated in Figure 3 by flow line 222 and the repetition of steps 
202, 206 and 208* During this repetitive prompting process, depending oh time elapsed and distance 
traveled, updated position information may be provided to server 136* If the refining prompts are 
stored locally in device 130 or unit 132, refinement occurs before the query is sent and this repetitive 
process will not usually be necessary. 

Once the request has been sufficiently refined, server 136 uses the refined request to retrieve 

■ 

data from database 138. Continuing with the examples described above, server 136 may retrieve 
locations of restaurants, gas stations, hotels, or other facilities or services near the user. In one 
implementation, the information is listed or ranked in order of best matches to the user's request 
and/or preferences. The listing of facilities or services matching the request is provided to handset 
130 over network 140 as shown in step 208, and the information is audibly or visually provided to 
the user as illustrated in step 210. If the information is provided audibly, audio data can be 

■ 

prerecorded or synthesized by server 136 and transmitted over network 140, or data can be sent 
across network 140 and speech synthesized locally. 

r 

i 

Once the user selects a facility or service from the list of options provided, server 136 can 
retrieve or compute driving directions to the facility or service based on the user's current position. 
If sufficient time has elapsed to significantly alter the user's current position, server 136 may request 
a position update. In one implementation, a speed of travel parameter is provided by handset 130 
along with the current position. In this implementation, the determination of whether to update the 
position information can be based in part on this parameter. Where the user is traveling at a higlj rate 

r } 
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of speed, positional updates will be required often to ensure accurate directions. Additionally, where 
the user is approaching a freeway exit or other waypoint in the route being computed, server 136 
may request a position update to ensure that this waypoint has not been passed. If it has been passed, 
an alternative route may be calculated or the user may be directed to backtrack to the passed 
waypoint. 

4. Converting HTML/XML to HDMLAVML 

■ 

Figure 4 portrays an extension of the previously described Figure 2 environment. In Figure 
4, an example configuration is shown that depicts a mobile unit 100 connected to the Web 150 
through server 136 and wireless network 140. Additionally shown in Figure 4 are four separate 

■ 

example illustrations of database 138, In one embodiment, database 138A contains information 
relating to the display properties and processing capabilities of mobile unit 100, Database 138B 

■ 

preferably contains information relating to the preferences of a user of mobile unit 100 while 
database 138C preferably contains conversion specifications for the translation of HTML/XML data 
to HDMLAVML. Finally, in this embodiment, database 138D contains HTML/XML documents 
from the Web that have been cached at the server 136 for future access. 

The process that converts HTML/XML to HDMLAVML begins with mobile unit 100 
requesting information from the Web 150. This request is initiated by the user of mobile unit 100 
and is transmitted to server 136 over wireless network 140 as described in the previously referenced 
Sending Local Information Patent In an alternative embodiment, the request can be initiated 
automatically by the mobile unit, hi addition to the URL that comprises the request for information 
from the Web 150, the request further includes certain information regarding the mobile unit 100 and 
the requesting user of the mobile unit 100* This device and user information corresponds to more 
detailed information located in database 138 A and 138B, respectively. 

i 

r 
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For example, the device information included in the request may uniquely identify the 
mobile unit 100 as the NeoPoint 1000 digital cellular ielephone by using the moniker "NP1K." 
Corresponding information in database 138A, however, illuminates all of the features and 

t 

characteristics specific to that device. Such information may include, but is not limited to, transmit 
and receive frequencies, interoperability standards, safety requirements, encryption specifications, 
weight, LCD dimensions, keypad features, button and knob features, flip features, microphone and 
earpiece characteristics, antenna specifications, internal clock information, battery type, memory 

■ 

capabilities, browser type, application support, and Short Messaging Service ("SMS'*) capabilities, 
internal processor specifications, and Over the Air Service Programming capabilities, to name just 
a few. 

Related information about the user of the mobile can advantageously be maintained in 
database 138B. The user of the mobile unit 100 is preferably identified by a shortened label, in a 
fashion similar to the identification of the mobile unit 100. Examples of information about the user 

M 

that can be stored in database 13 8B include but are not limited to full name, age, sex, marital status, 

■ 

preferred airline and seating arrangements, preferred fueling stations and fuel requirements (e.g, 
diesel, gasoline, propane, electric), credit card number(s), preferred restaurants and cuisine types, 
and the last recorded location of the user's mobile unit 

Turning to Figure 5, an example of a process for converting HTML/XML to HDML/WML 
is portrayed in flowchart form. As described above, the process is initiated by the mobile unit 100 

■ 

sending a request to the server 136 in step 220. Once the server 136 has received a request from 
mobile unit 100, the server 136 retrieves the requested document from the Web 150 as illustrated 
in step 222. The document retrieved from the Web 150 by the server 136 corresponds to the URL 

sent by the mobile unit 100, as is well known in the art. The process used by the server 136 to 

\ \ 
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retrieve the requested HTML/XML document is similarly well known to those having ordinary skill 
in the art. 

In step 224, the server 136 fetches the user preferences and/or user profile information from 
database 13 8B. For example, an incoming request might preferably contain separate keys that 
uniquely identify the user of the mobile unit, the' mobile unit itself, and the requested URL, 
Therefore, in this example embodiment, the server 136 parses the incoming request from mobile unit 
100, Aflerparsing the request, the server 136 performs a lookup in database 138B using the unique 
user key. In this fashion, the server 136 retrieves the user preferences and/or user profile information 
from database 1 3 8B . 

In a similar fashion, the server 136 fetches the device characteristics and specifications from 
database 13 8A as illustrated in step 226. Preferably, the characteristics and specifications are 
maintained and updated on an on-going basis to encompass the most recent upgrades and newer 

i- 

models of mobile units. In an alternative embodiment, the server 136 fetches the device 
characteristics and specifications from database 138A prior to fetching the user profile and 
preferences from database 138B, Additionally, in a multitasking multiprocessing embodiment, the 
server 136 may simultaneously fetch the user profile and preferences and the device characteristics 
and specifications from their respective databases. Moreover, to decrease response time, the 
database fetches can be carried out simultaneously with the retrieval of the requested HTML/XML 
document. 

■ 

* Based on the retrieved user preferences, device specifications, and content type of the 

^ • 

HTML/XML document, the server 136, in step 228, fetches the appropriate conversion specification 
or specifications from database 138C. For example, different mobile devices may have different 
display characteristics and the ability to display more or less rows and columns of characters. 
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Additionally, the content of the HTML/XML document may contain multiple images with differing 
image file formats. The color depth of the images may vary while the mobile unit 100 may only 
have the capability to display images in gray scale. 

■ « 

* 

Continuing the" example, the content of the JHML/XML document may contain frames and 
tables. The text in the HTML/XML document may contain varied formatting such as boldface type, 
different font types, and different font sizes. The content of the HTML/XML document may utilize 

■ 

radio buttons, popup menus, or on-focus user interface options. Finally, the content of the 
HTML/XML document may include scripts or applets that are not supported by a mobile unit. 
Therefore, depending on the preferences of the individual user, the characteristics of the display 
dfevice, and the content of the retrieved HTML/XML document, the server 136 fetches the 
appropriate conversion specification or specifications from database 138C. 

The conversion specifications contain abstracts of the desired data contained in the 
HTML/XML document. As discussed above, the content of an HTML/XML Web document may 
contain certain user interface elements that are not compatible with the mobile unit's 100 display. 
Thus, the conversion specifications relate the germane information from the HTML/XML structures 
to the necessary context for display on the mobile unit's 100 display. 

■ 

Once the conversion specifications have been selected, in step 230 the server 136 converts 
the native HTML/XML document into its corresponding HDML/WML counterpart. Once the 
HTML/XML document has been converted, the resulting HDML/WML is optimized in step 232. 
For example, to take maximum advantage of the wireless communications network and the 
processing power of the mobile unit, the optimization step reduces the size of the transmission to the 
mobile device. Additionally, according to the specifications and characteristics of the mobile device, 

the optimization step formats the display size of the HDML/WML cards and decks to utilize the 

i/'! 



19 



WO 01/86462 



PCTYUS01/14707 



entire display of the mobile unit 100. Finally, as shown in step 234 3 the optimized HDML/WML 
is tokenized and sent to the mobile unit 100 over wireless network 140, 

■ 

The tokenizing of the HDML/WML is a process that is well known in the art. The Amotion 

■ 

of tokenizing is to reduce the number of bytes required for transmission over the wireless network 

mm* 1 

140. This is accomplished by substituting well known and pre-defined character sets with numeric 
tokens. For example, a subset of HDML/WML code might look like the following: 

<WTUl> 

<card id^'abc" ordered- "true 11 > 
<P> 

<do type- 11 accept " > 

<go href = "ht tp://xyz, org/ s ,r /> 

</do> 

X.: $(X)<br/:> 

Y: $ (Y) <br/> 

Enter name: <input type= 1f text " name="N"/> 

</p> 
</card> 

</wml> 

The corresponding tokenized form of the above example (with numbers in hexadecimal 
form) might look like the following: 



01 


04 


6A 


04 


■X' 


00 




oo ■ 


7F 


E7 


21 


03 


■a' 


'b' 


■C 1 00 


33 


01 


20 


E3 


38 


01 


AB 


■ 4B 


03 






T z r 


00 


88 


03 


's' 


00 


01 


03 




■x r 


.i.i 


i r 


00 


82 


00 


26 


03 


t i 


i Y » 


* 


i i 


00 


82 


02 . 


28 


03 


i i 


»E r 


( n' 


! t 1 


'e» 


*r f 


T 1 


1 n l 


'a' 


'm' 


■e' 


T . f 


i i 


00 


AF 


48 


18 


03 


1 N 1 


00 


01 


01 


01 



The above condensed form of the HDML/WML code is annotated in the following table: 



01 


WBXML Version number Li 


04 


WML LI Public ID 


6A 


Charse1=UTF-8 (MIBEnum 106) 


04 


String table length 


'X T , 00, 1 Y 1 , 00 


String table 


7F 


Wml, with content 


E7 


Card, with content and attributes I i 
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cc 

mj 3 




03 


Inline string to Hows 




otnng 


33 

w —J 




01 


: END (of card attribute list) 


. D U 


P 


C4<3 


Do, with content and attributes 


J O 

f- * 


Type=accept 




END (of do attnbute list) 




Go, with attributes 




Href="http://" 


U j 


Inline string follows 


x f y / Z / o 


String 


ft 0 


fl / tm 

" * org/ " 




InUne string follows 


S / u 


String 


u J_ 


END (of go element) 


! n i 


END (of do element) 


U J 


Inline string follows 


r 1 r X 1 , T : f , 1 1 , 00 


String 


82 


Direct variable reference (EXT T 2) 


00 


Variable offset 0 


26 


Br 


03 


Inline string follows 


! 1 / 1 Y 1 , ' r 1 1 f 00 


String 


82 


Direct variable reference (EXT T 2) 


02 


Variable offset 2 


26 


Br 


03 


Inline string follows . 


11 1 E 1 1 l | f i_ r 1,1 ti am 

, 'E' f n.' , 't', e 1 , *r', • 

t f—, 1 | — , J ImI IaI 1*1 t 1 

lif'SL, ' til , S f • « / t)U 


String 


AF 


Tnnnh "With Qt+rn V*tt+^g 
J_IJ.jJU.l- j Willi ctLCTlUULCo 


48 


Type="text rr 


21 


Name- 


03 


Inline string follows 


•N 1 , 00 


String 


01 


END (of input attribute list) 


01 


END (ofp element) 


01 


END (of card element) 


01 


END (ofwml element) 
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A flowchart of an example process for converting HTML/XML to HDML/WML is 

* 

illustrated in Figure 6. This process is an expansion of the previously described step 230- Initially, 
in step 240 the content of the HTML/XML document is parsed by the server 136. This parsing 
separates the content into corresponding key - value pairs. These pairs represent the format and the ' 
context of the elements that comprise the HTML/XML document For example, a sample set of 
HTML/XML code might look like the following: 

<html > 

<head> 

<title>EdgeMail : POP Mariager</title> 
</head> 
<body> 



< TABLE WIDTH=520 cellpadding=l cellspacing=0 
border=0> 
<TR> 

<TD width^50%xFONT FAGS =ARI AL >F1 ight 
#l</FONTx/TD> 

<TD align=right width=50%xFONT 
FACE=ARIALxB>Departure Date: 
• </Bx/FONTx/TD> 

<TD align=left width=50%xFONT FACE=ARIAL>Nov 
19, 1999</FONTx/TD> 
</TR> 
< /TABLE > 



</body> 
</html> 

Continuing the example, the corresponding key - value pairs to the above sample code might 
look like the following; 



ROOT Jitmll ,headl .titlel .text 1 
ROOT.htmll .headl .stylel .type 
ROOT.htmll .headl .stylel .textl 
ROOT.htmll .body 1 *tablel .border 
.ROOT.htmll .body Ltablel .cellspacing 
ROOT.htmll .body Ltablel .cellpadding 
ROOT.htmll. body LtableLwidth 
ROOT.html 1 .body 1 .table 1 . tr L td 1 .class 
ROOT.htmll .body 1 .tablel .tr 1 .tdl .width 
ROOT.htmll .body 1 .table 1 .tr 1 .td 1 . text I 



EdgeMail: POP Manager 
text/ess 

Span.c2 {font-family: ARIAL} ticl 

0 

0 

1 

520 
cl 

50% 

Flight #1 
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ROOT.htmll.bodyLtablel,trl.td2.width 50% 

ROOT.htmll .body 1 .table Ltrl .td2.align Right 

ROOT.htmII,bodyl.tableLtrl.td2.spanLclass c2 

ROOT.htmIl.bodyLtableLtrLtd2.spanl,bLtextl Departure Date: 

ROOT.htmll .bodyl .table Ltrl .td3 .class cl 

ROOT.htmllvbodyl.tablel ,trl.td3.width 50% 

ROOT.htmiLbodyLtablel.trUd3.align left 



After the HTML/XML code has been parsed into its constituent key - value pairs, the server 
136 filters out the non-essential content. This filtering process is based on the specifications and 

* 

characteristics of the mobile unit For example, if the mobile unit does not have "the ability to display 
graphics, the filtering process of step 242 substitutes the text corresponding to the graphic and thus 
filters out the graphical elements of the content. In a preferred embodiment, the server 136 similarly 
filters out unnecessary textual items* For example, all comments can be removed. Additionally, 
textual data in tabular format can be reformatted into lists. Continuing the example, a very large 
table can be converted into multiple lists. Long textual entries can be converted into multiple cards 
in the HDMLAVML deck. Alternatively, for a mobile unit that has the ability to display graphics, 
the image size can be reduced, the image file format can be converted to a format supported by the 
mobile unit, and the color depth can be optimized for display on the mobile device. In this fashion, 
the server 136 filters out the unnecessary content from the key - value pairs. 

Next, in step 244, the server 136 converts the key - value pairs into HDML/WML. For 
example, the tables that were converted to lists above are formatted in HDMLAVML structures such 
that the lists correspond to cards in an HDMLAVML deck. In a preferred embodiment, the server 

-■ 

136 recognizes the context of each, element of the filtered content by the nature of the key - value 
pair for that element. Thus, the server 136 restructures the filtered elements into HDMLAVML by 
wrapping those elements in the corresponding code segments for the HDMLAVML card and deck 
paradigm. For example, the above referenced key - value pairs are the following: 
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ROOT.htmll.headl.titlel.textl EdgeMail: POP Manager 

ROOT.htmIl.headl . style 1. type text/ess 

R06T.htmll.headl.stylel.textl Span.c2 {font-family: ARIAL} td.cl 

ROOTJitmll. body 1. table 1. border 0 

ROOT.htmll.bodyl.tablel.cellspacing 0 

ROOT.htmlLbodyl.tablel.cellpadding 1 

ROOT.htmll. body l.tablel. width 520 

ROOT.htmll .bodyl.tablel.tr U'di.class cl 

ROOT.htadl.bodyl.tabIel.trl.tdl.widm . 50% 

ROOT.htmIl.bodyl.tablel.trl.tdl.textl FKght #1 

ROOT.htmll. body 1. table 1 .trl .td2. width 50% 

ROOT.htmIl.bodyl.tablel.trl.td2.aIign Right 

ROOT.htrall .body 1 .tablel .trl .td2.span 1 .class c2 
ROOT.htmll .bodyl .tablel .trl ,td2.spanl .bl .textl Departure Date: 

ROOT.htmll.bodyl.tablel .trl .td3.class cl 

ROOT.html 1 .body 1 . table 1 .trl ,td3 .width 50% 

ROOT.html 1 .body 1 .table 1 .trl .td3 .align left 



After conversion into HDML/WML, these key - value pairs may look like: 
<wml> 

<card> 

<p mode="nowrap"/>Flight #l:</p> 

<p mode="nowrap"/>Departure. Date: Nov 19, 1999</p> 
</card> 

< /wral > 

After this conversion process, the resulting HDML/WML code is optimized as described 
above with reference to step 232. Finally, as described above with reference to step 234, the 
optimized HDML/WML code is tokenized for reduction in transmission size and sent to the waiting 
mobile unit 1 00 for display to the user of the wireless communications device, * 

While the particular method of converting HTML/XML to HDML/WML in real-time for 
display on wireless communication devices herein shown and described in detail is fully capable of 
attaining the above described objects of this invention, it is to be understood that the description and 
drawings represent the presently preferred embodiment of the invention and are, as such, a 
representative of the subject matter which is broadly contemplated by the present invention. It is 
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further understood that the scope of the present invention fiilly encompasses other embodiments that 
may become obvious to those skilled In the art, and that the scope of the present invention is 
accordingly limited by nothing other than the appended claims. 
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What is claimed is: 

1 . A method for converting HTML/XML to HDML/WML 
comprising the steps of: 

at the mobile unit, sending a request to a proxy server; 

at the proxy server, retrieving the requested HTML/XML 
document from the Web, retrieving a conversion specification, 
retrieving mobile unit device information, extracting needed 
data from the HTML/XML document, format the extracted 

r 

data in HDML/WML, optimizing the HDML/WML data for 
transmission, and transmitting the HDML/WML data to the 
mobile unit for display. 

2. The method of claim 1 wherein said request contains 
information pertaining to the mobile device. 

3 . The method of claim 1 wherein the proxy server retrieves the 
requested HTML/XML document from local cache. 

4. A method for a Web server to convert HTML/XML to 

■ 

HDML/WML comprising the steps of: 

■ 

retrieving a requested HTML/XML document from the 
Web; 

parsing the HTML/XML code to generate key/value pairs; 
filtering the key/value pairs into the relevant subset; 
translating the key/value pairs into HDMLAVML card/deck 

26 
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pairs; and 

tokenizing the HDML/WML card/deck pairs* 

5. The method of claim 4 wherein said request is sent by a 
wireless communications device and said request comprises: 

a Uniform Resource Locator; 

a key that uniquely identifies said wireless communications 
device; and 

a key that uniquely identifies the user profile of said 
wireless communications device. 

6. The method of claim 5 wherein the Web server retrieves said 
requested HTML/XML document fiom local cache. 
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